[Access] Unify subscription id with client message id #6847
Conversation
From now on, we use only 1 id in request/response messages. This id is called `subscription_id`. A client may provide `subscription_id` in `subscribe` request. If client does not provide it, we generate it ourselves. Clients that use browsers or other async environemnts may use `subscription_id` to correlate response messages with the request ones. `subscription_id` is used in all messages related to subscription. I also remove `success` field from response. We include `subscription_id` field in a resposne in case of OK response. In case of error response, we include `error` field.
illia-malachyn
force-pushed
the
illia-malachyn/6845-unify-subscription-and-message-id
branch
from
8d1e427 to
e5a91d7
Compare
illia-malachyn
changed the title
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #6847 +/- ##
==========================================
- Coverage 41.08% 41.07% -0.01%
==========================================
Files 2121 2121
Lines 185905 185901 -4
==========================================
- Hits 76373 76366 -7
- Misses 103118 103121 +3
Partials 6414 6414
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
| return uuid.New(), nil | ||
| } | ||
|
|
||
| newID, err := uuid.Parse(id) |
There was a problem hiding this comment.
@jribbink what do you think about requiring clients pass UUIDs (32 character hex strings) for the client ids? Is that reasonable or too restrictive?
There was a problem hiding this comment.
FYI, if we require clients to create subscripion_id on their side, we can go with a simple integer value for subscription_id as a client will have control over random number generation.
There was a problem hiding this comment.
For now, we decided not to require clients to provide valid uuid but rather a random string containing N characters
Client is not required to provide valid UUID for subscription ID from now on. It can be any string [1-20] characters long. If no subscription ID provided, server creates UUID string for it.
|
@Guitarheroua can you take a look at this one |
Will double check it |
Guitarheroua
deleted the
illia-malachyn/6845-unify-subscription-and-message-id
branch
From commit message:
From now on, we use only 1 id in request/response messages. This id is called
subscription_id.A client may provide
subscription_idinsubscriberequest. If client does not provide it, we generate it ourselves.Clients that use browsers or other async environments may use
subscription_idto correlate response messages with the request ones.subscription_idis used in all messages related to subscription.I also removed
successfield from a response. We includesubscription_idfield in a resposne in case of OK response.In case of error response, we include
errorfield.Closes #6845